项目 内容
这个作业属于哪个课程 课程社区
这个作业的要求在哪里 作业要求
我在这个课程的目标是 通过一定的软件开发流程，在预计时间内发布”足够好”的符合用户需求的软件，并证明其是可维护和持续发展的。
这个作业在哪个具体方面帮助我实现目标 帮助掌握独立思考以及提问有价值的问题的能力

问题一：goto函数的是否使用问题？

在第4章《两人合作》的4.3《代码设计规范》一节的4.3.2 goto中有原文如下：

1
2
3
4
5
6
7
8
9
10
11
12
    函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto...
```       
书中认为，goto可以有助于程序逻辑的体现，因此可以使用。      
但是这与我从大一到现在学习的《C语言程序设计》等课程所教授的理念**不相符**。        
而查阅资料发现Dijkstra曾在[A Case against the GO TO Statement.](https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD215.html)一文中阐述了反对`goto`语句的理由—— 1. **真正的工作是由"进程"来完成，而非程序**；2.**人脑善于处理静态关系，不善于想象随时间进行的动态执行流程**。因此，应该**尽可能让文本中的程序与时间轴上的进程对应的尽可能的简单**。      
我的观点是`goto`语句会使得编程变得不可控，使用后可能会导致部分程序**达不到预期的效果**。      
我的问题是作者为何鼓吹如今几乎在大多数语言中都不怎么使用，甚至没有相应的设计的`goto`语句呢？这真的能够很好的有助于程序逻辑的体现嘛？还是一把**双刃剑**？

# 问题二：AI流行的大背景下软件团队模式是否可能会出现超级个体的模式？
书的第5章《团队和流程》的第5.2节 《软件团队的模式》有如下原话：
```tex
软件团队有各种形式，适用于不同的人员和需求。...

并在此后提出了近10种团队模式，例如：交响乐团模式和爵士乐模式等，这些团队无一例外都是由多人组成。
但是在当前AI大模型横行的当下，一人成军或许已经可行？已有案例，其复刻了一套AI工作流：

  1. 让 AI 扫描全球各行业的公开数据，找「有人需要但没人做」的应用缺口。产品主要面向海外市场，比如美国建筑行业工具、西班牙耗水监测 App、新加坡工程管理软件等。
  2. 把筛选出的需求转成功能清单，交给 AI 写代码。
  3. 第二天醒来验收上架，每天花不到 1 小时。单款成本几百块，不行就关掉换下一个。

我的观点是就目前的AI水平可能还无法真的达到在保证产品质量高和低成本等的平衡，生产出来的产品也只是满足一些偏低级的需求的产品。
但是我不知道随着AI的持续发展，是否真的能够做到一人成军，或者说出现两三个人加上一大堆AI组成的团队模式——养龙虾模式？如果这种模式真的能够取得成功，那么软件工程又将何去何从？

问题三：“探索式”的测试太多真的意味着团队管理不佳嘛？

书中第13章《软件测试》的13.2节的各种测试方法中的13.2.4 “探索式”的测试(Ad hoc Test)中有如下表述：

1
作为管理人员来说，如果太多的小强是在探索式测试中找出来的，那我们就要看看测试计划是否基于实际的场景，开发人员的代码逻辑是否完善，等到。同时，要善于把看似探索式的测试用例抽象出来，囊括到以后的测试计划中。因此，探索式测试太多是团队管理不佳的一个标志，因为探索式测试是指那些一时想到要做但以后并不打算经常重复的测试。

通过查阅维基百科，得出对于其定义为

1
Ad hoc testing is a commonly used term for planned software testing that is performed without initial test case documentation;

是一种没有提前文档安排的临时测试，因此有着可能无记录的弊端，但是大多数测试人员仍然打算将自己的方法论应用于整个软件开发过程中，以查找计划测试用例未预料到的缺陷，并根据具体情况选择合适的方法。
我的观点是这种测试是原先安排好的测试的一种很好的补充，它的出现恰恰说明了我们离理想状态更近了一步，而由于bug是无穷无尽的，并且随着用户需求的不断变化，新的bug可能层出不穷。这时仅仅靠预先的文档中的测试方式可能并不能很好的测试出所有的bug，在这种情况下，”探索式”测试就难得可贵了。
因此，我认为“探索式”的测试太多并不意味着团队管理不佳，而只是代码状态的再完善，是对于一些边界条件的再讨论起点，那么一刀切死是否过于绝对了？

问题四：关于伙伴测试的一点疑惑？

书中第13章《软件测试》的13.2 各种测试的第13.2.7节 《伙伴测试》提到了

1
我们这里要讲的伙伴测试是指开发人员可以找一个测试人员作为伙伴，在签入新代码之前，开发人员做一个包含新模块的私人构建，测试人员在本地做必要的回归/功能/集成/探索测试，发现问题直接与开发人员沟通，通过伙伴测试把重大问题都解决了之后，开发人员再正式签入代码。

通过查阅相关博客资料，知道了伙伴测试的优劣性，例如：增加对他人依赖性，因为两名测试人员必须合作才能成功。如果其中一名测试人员无法参与测试，则可能会延迟或扰乱测试进度。但是我还有一些困惑。
这种伙伴测试的伙伴之间的关系与第2章 《两人合作》中小组中的两人之间关系有什么相似之处和差别嘛？这种测试方式是否是一种绑定测试人员的情况，即这种测试是否会占用测试人员的名额，进而导致团队过于冗余？

问题五：只能做猪、鸡或者鹦鹉嘛？

书中第17章 《人，绩效和职业道德》中的17.4节 《猪、鸡和鹦鹉的故事》中提到了

1
在一个团队中，有些人是猪、有些人是鸡、有些人是鹦鹉，是由他们与团队项目关联程度作为区分的。

此处作者将团队中的人划分为三类进行讨论，是否过于简化现实情况，比如，随着项目的推进鸡变为猪之类的动态变化。因为对于一些初创团队来说，没人知道它是否会成功，大家可能一开始都是鸡，但是随着项目的逐步成功，或许有些人逐渐变成了猪。
因此，我认为不应该简单的将团队里的参与程度简单的身份化，或许用实时的变化趋势来表示更为准确？此外，我还好奇在AI横行的当下，鹦鹉是否也能拥有发言权？